home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16071 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  5.0 KB
  1. Path: polyhdrn.demon.co.uk!catherine
  2. From: Catherine Rees-Lay <catherine@polyhdrn.demon.co.uk>
  3. Newsgroups: comp.lang.c++,comp.lang.delphi,comp.lang.pascal.delphi.misc,comp.os.ms-windows.programmer.misc,comp.os.ms-windows.programmer.tools,comp.os.ms-windows.programmer.tools.misc,comp.windows.ms.programmer
  4. Subject: Re: HELP: C++ or DELPHI ? We need translate DOS program which written in BP/TV.
  5. Date: Tue, 9 Apr 1996 14:18:48 +0100
  6. Organization: Polyhedron Software Ltd
  7. Distribution: world
  8. Message-ID: <X2XD9EA4OmaxEwNe@polyhdrn.demon.co.uk>
  9. References: <DoJ6yG.FIn@actcom.co.il> <315C20CD.7CEE@airmail.net>
  10.  <828295369snz@display.co.uk> <315FF327.1FF2@airmail.net>
  11.  <31609D7C.5833@millennianet.com> <316166F5.6972@airmail.net>
  12.  <31628098.7239317@news> <31638C5E.608@airmail.net>
  13. NNTP-Posting-Host: polyhdrn.demon.co.uk
  14. X-NNTP-Posting-Host: polyhdrn.demon.co.uk
  15. MIME-Version: 1.0
  16. X-Newsreader: Turnpike Version 1.12 <yZu$HUJ4S2jUGzAcu5QzBnLOPH>
  17.  
  18. In article <31638C5E.608@airmail.net>, Brian Ebarb <ebarb@airmail.net>
  19. writes
  20. >Brien King wrote:
  21. >> No, Delphi, is basicly Turbo Pascal for Windows 8.0.  The compiler and
  22. >> tools have been around for a long time.  Delphi adds a lot of new
  23. >> things to a well proven compiler (atleast thats true for 1.x, don't
  24. >> know about 2.x)
  25. >
  26. >Check my previous message. I wasn't talking about the Delphi COMPILER.
  27. > 
  28. >> I really don't see a limitation in Delphi that would prevent it from
  29. >> being used in any size application.  Can you be a little more
  30. >> specific?  Are we taking Data size, Code Size, or????
  31. >
  32. >I work on some pretty huge apps. One which was recently delivered 
  33. >involved hundreds of dialogs which used various database and 
  34. >communication interfaces supplied by various third parties. Throw in a 
  35. >strict minimum system configuration requirement and the options for 
  36. >viable development tools becomes pretty short. PowerBuilder was tried, 
  37. >but long before half of the dialogs were drawn PB was sucking up system 
  38. >resource at an absolutely unacceptable rate. To the project's credit, a 
  39. >Visual Basic implementation was never attempted. VB (and presumably 
  40. >Delphi) are fine for many applications, just not these.
  41. >
  42. If you're considering Delphi to be only as suitable as VB for writing
  43. large apps, you're wrong. It may look similar superficially, but while
  44. VB allows you to draw forms and write code to link them together, Delphi
  45. is basically a powerful Windows API-using compiler like VC, which just
  46. happens to have a VB-like interface on the front to make design easier. 
  47.  
  48. Some of the Delphi components do use a lot of resources, no question
  49. about it. However, the beauty of Delphi is that if this is a problem for
  50. you, you could just link in a resource script and program your
  51. dialog/window/whatever directly with API calls, thus incurring exactly
  52. the same overhead as for a C++ app using the API directly. And you can
  53. mix-and-match this with RAD-type code to suit your particular situation. 
  54.  
  55. Personally I've always used the SDK documentation for the Windows API -
  56. I think any programmer competent to use the API should be able to deal
  57. with the different syntax :-) 
  58.  
  59. >> I'm sure that claim could be made about any language.  COBOL anyone?
  60. >
  61. >COBOL _can_ handle workload found in large global applications. 
  62. >
  63. So can Fortran. My current project is a Windows conversion of a "legacy"
  64. Fortran app. Now I could have written a GUI using the API directly from
  65. Fortran, or I could have called the API from a VC front end and
  66. connected to a Fortran DLL. I'm using Delphi + a Fortran DLL which IMHO
  67. is much simpler for the basic stuff. I can call the API where I need to,
  68. but I certainly don't want to write the entire interface using it for
  69. the sake of having my GUI in a more computationally powerful language! 
  70. Equally I see no good reason to rewrite many thousands of lines of
  71. computationally intensive Fortran in Delphi, C++ or anything else.
  72. People always say "use the right tool for the job" but fail to realise
  73. that "the job" is often a part of the project rather than necessarily
  74. the whole of it. For Windows GUI-building I'd take Delphi every time. 
  75.  
  76. >> Better brush up on your VB skills since thats the way Micro$oft is
  77. >> heading.
  78. >
  79. >Hmmmph. There'll always be a need for VC. What'll they write VB in? 
  80. >Microsoft can lead users over any cliff they want, but I'm sticking to 
  81. >the most powerful development environment offered by a given OS vendor. 
  82. >When I do Solaris, I use Sun development tools. When I do Windows, I use 
  83. >MS. When I do OS/2, I use IBM. At least I know these tools will be 
  84. >around as long as their respective OS's are. (OK, I fudge a little. I 
  85. >use Watcom for NLM's, but that's OK - Novell doesn't make a compiler).
  86. >
  87. I take it you've never been a Fortran developer. Microsoft stopped work
  88. on their 16-bit DOS/Windows 3.1 compiler years before Windows 95 came
  89. out. So much for OS vendors keeping up their own tools :-(
  90.  
  91. Catherine.
  92. Catherine Rees-Lay                 Catherin@polyhdrn.demon.co.uk
  93. Polyhedron Software Ltd.        
  94. Programs for Programmers - QA, Compilers, Graphics
  95. ************ Visit our Web site on http://www.polyhedron.co.uk/ ************
  96.